Per review on #3340: a single file-system event can trigger many 'add' or
'change' callbacks in quick succession (e.g., a git checkout or a bulk
editor save), which would previously cause one restart per event.

Wrap onSuccess in a 150ms trailing debouncer so bursts of events collapse
into a single restart. 150ms is below human-perceivable latency but large
enough to coalesce filesystem event storms on all tested platforms.

Verifies both the positive path (flag emits .d.ts files alongside .js)
and the negative path (default SWC build does not emit declarations).

The scaffolded app's node_modules contains the published @nestjs/cli,
which bin/nest.js delegates to via localBinExists(). The new
--emit-declarations flag doesn't exist there yet, so the test fails
with 'unknown option'. removeLocalCli() forces the dev CLI to run.

The SWC compiler delegates declaration emission to 'tsc --emitDeclarationOnly',
which silently produces no output when declaration: false. The default
NestJS scaffold sets declaration: false in tsconfig.build.json, so enable
it in the test via a targeted write (restored in a finally block so
subsequent tests aren't affected).

…ailure

Previous test asserted specific .d.ts paths. When those assertions failed
on CI, there was no signal about where the files actually landed (or
whether tsc silently emitted none). Replace with a recursive walk of dist/
plus diagnostic logging of nest build output and dist contents, so the
next failing run tells us exactly what happened.

Also enable declaration: true in tsconfig.json (not just tsconfig.build.json)
in case nest resolves the root tsconfig when invoking tsc --emitDeclarationOnly.

…set-change

feat(assets): restart app on asset change in watch mode (#2626)

feat(swc): add emit declarations flag for type definition generation

Closes #1845

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…r deps

The scaffoldMonorepoWithDeps helper uses a naive capitalize-first-letter
transform that produces invalid TypeScript identifiers like `My-libModule`
when the sub-app name contains a hyphen. Renaming the test's sub-app from
`my-lib` to `mylib` sidesteps the issue without changing the helper.

Two CI failures were masking each other:

1. scaffoldMonorepoWithDeps scaffolds an ESM project (since `nest new`
   defaults to type: module in v12), but the manually-written sub-app
   source files use CJS-style imports without .js extensions. With
   moduleResolution: NodeNext this fails with TS2307 'Cannot find module
   ./mylib.module'. Calling convertToCjs() aligns the project format.

2. includeLibraryAssets is introduced by this PR and absent from the
   published @nestjs/cli that the scaffolded project installs, so
   bin/nest.js delegates to a CLI that ignores the option. removeLocalCli
   forces the dev CLI to be used.

With tsconfig include: ['src/**/*'], tsc infers rootDir as src/, so the
compiled main.js sits directly at dist/apps/<name>/main.js — not under
a src/ subdir. Matches the path assertion used by the existing webpack
monorepo test in build.command.e2e-spec.ts.

…ests

Existing closeWatchers and onSuccess tests need an additional
mockReturnValueOnce([]) entry to account for the new
includeLibraryAssets getValueOrDefault call introduced by this PR.
Without it, the mock chain shifts and tests fail with TypeError when
sourceRoot resolves to a non-string.

Add an opt-in --format flag to nest generate and nest new commands.
When passed, the format option is propagated to the schematic so it
can format generated files (e.g. with Prettier) before writing them
to disk. The default is off, so no existing project behavior changes
unless the flag is explicitly enabled.

This is the CLI-side change. The actual formatting logic lives in
@nestjs/schematics.

Closes #316

Exercises two paths through the format option wiring:
- nest generate controller <name> --no-format -> format=false is
  accepted and the controller is still generated.
- nest generate controller <name> (flag omitted) -> format
  defaults to true and the controller is generated.

The tests do not assert that prettier formatting has actually been
applied because the companion @nestjs/schematics change lives on a
separate major release line; here we only want to guarantee the CLI
parses the flag and passes it through without regressing other
generate paths.

feat(generate): pass format option to schematics

The `getRspackConfigPath` helper already honours `cmdOptions.rspackPath`
and its unit tests cover the CLI-path precedence case, but neither the
`build` nor the `start` command wires the flag through from commander.
As a result, projects using the rspack builder could only point at a
custom rspack config via `nest-cli.json`, with no equivalent of the
existing `--webpackPath` CLI option.

Mirror the existing `--webpackPath` pattern:

- register `--rspackPath [path]` on both `build` and `start` commands
- forward `options.rspackPath` into the respective command contexts
- extend the `BuildCommandContext` / `StartCommandContext` interfaces

Also adds a unit test confirming the option flows from the build action
into `getRspackConfigPath`.

`retrieveCols` (used to center-pad the post-install banner printed after
`nest new`) only asked the shell for the terminal width via `tput cols`.
On Windows, `tput` is not installed by default, so the call always threw
and the function silently fell back to the hard-coded 80 columns — even
for users with wider terminals. The same fallback also kicks in whenever
`tput` is missing from a sandboxed or minimal Linux image.

Ask Node first: `process.stdout.columns` is maintained by the runtime on
every platform and reflects the actual terminal width (or `undefined` /
`0` when stdout is not a TTY). When it is a positive number, use it
directly and skip the `execSync` call entirely — this removes a small
per-invocation process spawn as well. Keep the existing `tput cols`
path and the 80-column default as secondary/tertiary fallbacks for the
non-TTY case.

Also adds unit tests covering the three branches (stdout.columns set,
tput fallback, and the final default).

Backports the master-branch fix for #3229 (PR #3275) to v12.0.0. The
`@nestjs/schematics` resource generator defines `--type` and `--crud`
options in its schema.json, but the v12 CLI does not register either
flag on the `generate` command. Running:

    nest g resource users --type rest --crud

exits with "error: unknown option '--type'" even though the schematic
itself would handle both flags correctly.

- register `--type [type]` and `--crud` on the generate command
- forward both into the generate action and on to the schematic
- only forward `--crud` when explicitly passed (avoid toggling default
  behavior on users who never opted in)

The master-branch PR noted that "no automated tests were added because
there are no existing e2e tests for generate resource" — this PR adds a
focused unit spec for `GenerateAction` covering forwarding of the new
options individually and together.

feat(generate): accept type and crud options on the resource schematic

fix(new): prefer process.stdout.columns over tput for terminal width

feat(cli): add rspack config path option to build and start commands

…aries

feat(assets): add option to include library assets in app builds